Netware Super Library/Netware Super Library.iso/inet_tcp/senddisk/senddisk.doc

Text File | 1989-07-06 | 12KB | 214 lines

SENDDISK - a utility to backup hard or floppy disks via command-line based
ftp programs on IBM personal computers and compatibles. (Note: this version
of SENDDISK does not contain a restore feature - retrieval of backed up files
would have to be done manually by using your existing ftp program).

REQUIREMENTS:
------------
1. The files in the SENDDISK package (SENDDISK.EXE, SENDDISK.DOC and BAT.COM).
2. A functioning command-line based ftp program on your PC. Note: the only
   tested FTP programs so far are those from the following TCP/IP packages:

        A. NCSA telnet (public domain)
        B. PC-NFS (Sun)
        C. PC/TCP (FTP Software, Inc.)
        D. IBM TCP/IP

   I cannot guarantee SENDDISK will work with any others (I'd give it about a
   50/50 chance - give it a try - if you send in a request to get SENDDISK
   working with another package, I'll give it a shot <[e-mail]
   128.174.73.105>).
3. An account on a machine (reachable by your PC's ftp program) that supports
   FTP requests (backing up to any other than a UNIX machine has not been tested
   - also, backing up to a machine with a flat file system is not recommended,
   as SENDDISK attempts to recreate the directory structure of your PC's drive)


What SENDDISK will need to know:
-------------------------------
1. the drive to transfer (default is current drive.)
2. the name of the remote host as you would specify it when using ftp
   (no default - this is explicitly asked for.)
3. a login/password combination to use for the ftp connection.
4. A name to use as the name of a subdirectory that will hold the backup.
5. Whether to transfer files incrementally (sending files created or modified
   since the last run of SENDDISK) or completely (sending all files on the
   volume). The default is "incrementally".
6. The ftp program to use. SENDDISK does its best to find an ftp program in the
   current path, but if it can't locate one, you will be prompted for it's file
   specification.

Once SENDDISK has all the necessary information, it is presented on screen for
confirmation, and you are given options to change any of the parameters before
beginning the transfer process. Once you confirm, SENDDISK attempts a trial
connection with the chosen host to make sure all is well. If that is successful,
SENDDISK scans the selected drive, creating a script for the ftp program (the
script is contained in a temporary file called ftpbak.bat in the root directory)
The script will instruct ftp to send files to the remote host (in "binary" or
"image" mode), recreating the volume's directory structure as it goes along (if
it doesn't already exist from a previous backup). When the script is complete,
ftp is called and the script is "fed in" as input.

After the transfer is over and if SENDDISK detects no errors, the files that
were backed up are then marked (by setting the DOS archive bit). After this is
completed, SENDDISK acknowledges a successful run and exits to DOS.


A Typical First SENDDISK Session (note: your mileage may vary, etc.):
--------------------------------------------------------------------
Upon running the program, you are presented some information on SENDDISK, its
author, where to ask questions or make requests, etc.

You are first asked to type in the name of the remote ftp host. You should
identify the host EXACTLY as you would when using ftp, as all that SENDDISK does
with this is call your ftp program with the entered name as argument.

You are then asked to enter the login and password to be used when establishing
the ftp connection.

Now you are prompted for a name to be used as the name of a subdirectory that
will contain the directory structure of your PC. Note that SENDDISK creates
an exact replica of the directory structure of the transferred volume (e.g.
if your PC has a subdirectory \APPS\NEW, and the name you type in here for
SENDDISK is MyPCbackup, then your account on the remote host will have a
subdirectory MyPCbackup/APPS/NEW - the whole tree structure is maintained and
is rooted at the directory MyPCbackup.)

At this point, the screen will be cleared, all transfer information will be
displayed, and you are asked to confirm it. Check to make sure all the
information is as you desire, especially the drive being sent and the ftp
program being used. If this really is your first transfer, make sure you
toggle the backup mode from the default of "incrementally" to "completely"
(this MUST be done at least once, otherwise some files <those with their DOS
archive bit previously reset for some reason> may not <ever> be backed up.)

When you are satisfied that everything is correct, type g to go ahead, as
instructed by directions on the screen.

Until the ftp transfer actually starts, you may press ESC to gracefully abort
SENDDISK (Ctrl-C or Ctrl-Break exits are strongly discouraged) (you may have
to be patient - don't worry - SENDDISK will halt what it's doing at the first
logical stopping point.) When the ftp transfer session starts up, however, it
is your ftp program that is in total control - ESC will not work here.

If all goes well, SENDDISK will confirm a successful transfer before exiting
to DOS.

Suggested Backup Strategies:
---------------------------
*  Do a complete backup at least once - otherwise some files may not be saved.

1. If you use the same subdirectory name using incremental mode every time you
   backup your drive, SENDDISK will add in new files to the backup structure on
   the remote host and overwrite updated versions of the same file.

  Note:

  - If you use this method, even though you may delete files on your drive,
    they will still (in general - see next note) exist on the remote host. That
    is, new files <and, of course, new directories> will be added to the
    structure every time you backup and thus the size of the backup structure as
    a whole will generally increase and the growth will depend on the turnover
    of the files on your PC's volume.

  - If you use this method, when you delete a file from your drive, most of
    the time it will remain on the remote host, but NOT ALWAYS. The only way it
    would be wiped out is if you created a different file with the identical
    name as the old one in a directory with the identical name as the old one
    and then ran SENDDISK - generally unlikely, but not impossible.

2. If you use a different subdirectory name each time you do an incremental
   backup, you can be sure that you will never lose a file that was backed up
   even if you delete it from your hard or floppy disk. You could, for instance,
   choose subdirectory names such as "hard_drive_backup.7-3-89" that include the
   date. All new or changed files since the last time you used SENDDISK would be
   sent to the remote host. For example, a new file \UTIL\PKUNZIP.EXE would be
   stored on the remote host as ...

         ~<your account name>/hard_drive_backup.7-3-89/UTIL/PKUNZIP.EXE.

   SENDDISK always creates any necessary subdirectories, as needed, on the
   remote host.

  - If you choose this method, note that it will take up more space on the
    remote host than method 1 since you will, in general, have many copies of
    frequently updated files scattered among the seperate backups.

  - One big disadvantage to using this method is that if you ever have to
    restore your hard disk from scratch, it will be much more awkward to
    transfer back the necessary files, since they will be scattered among
    several (perhaps many, many) subdirectory structures.

Restoring Files:
---------------
As mentioned, SENDDISK does not have a restore feature (reasons explained in
the next section). In the event that you have to restore files, you would use
your ftp program to contact the remote host, and navigate through the backup
structure(s) you have created with SENDDISK, transfering back any needed files.
*NOTE* You MUST explicitly specify the transfer mode as "binary" or"image" -
otherwise, any transferred files will be CORRUPT. Transfering by hand using ftp
is not as bad as you might think because any ftp worth its salt has a wildcard
feature available to transfer many files with one command.


More About SENDDISK:
-------------------
Some may say that SENDDISK is somewhat makeshift.
I agree.

A "really good" ftp backup utility would contain its own ftp communications
capability and not rely on someone else's ftp program. However, this would
entail programming at a very low level (TCP/IP at the network card I/O level)
and I'm not quite comfortable with that kind of programming yet. Also, I would
have to have a driver for all the various network cards that go into PC's these
days. This, in itself, would be a major, major undertaking.

A "really good" ftp backup utility would be able to restore files as well as
save them. However, given the above neccessity that SENDDISK cannot communicate
*directly* with the remote host, there is no practical way of keeping a reliable
record of precisely *what* files are actually on the remote host. SENDDISK has
no practical way of knowing what to restore.

A "really good" ftp backup utility wouldn't rely on a third party batch language
extension - it would be self-contained. SENDDISK needs BAT.COM to work. BAT.COM
is part of EBL (Extended Batch Language), a shareware product from Seaware Corp.
- P.O. Box 1656, Delray Beach, FL 33444. (By the way, I highly recommend EBL as
a very powerful addition/replacement for DOS batch language - the shareware
distribution package also includes the following files - BATDOC.BAT, BATDOC2.BAT
BATDEMO.BAT and BATFUNC1.BAT - paying the shareware registration of $49 gives
you an excellent manual, many, many more functions, and excellent support via
BBS and phone - the latest version of the publicly distributable version of
EBL can usually be found via anonymous ftp to uxe.cso.uiuc.edu <128.174.5.54>
in /pc/all or /pc/exec-pc).

I use BAT.COM mainly for two things:

        1. to do the actual piping of commands to arbitrary ftp programs via
           a modified DOS keyboard buffer.
        2. to scan the screen after the ftp program exits in order to identify
           errors that occured in ftp.

The first reason necessitated the use of EBL, as I was reluctant to program
at the BIOS level in order to queue up arbitrarily many characters in the
keyboard buffer.

Thus , SENDDISK is makeshift, I agree, but neccessarily so, in my case. It
*CAN*, however, make the job of backing up someone's hard drive much, much
easier to deal with if he just happens to be on a TCP/IP network (a growing
phenomenon these days, you know). Just set it up and let it fly (and go have
lunch).

As I become a more experienced programmer, later versions of SENDDISK will
resolve the makeshift aspects, and also add a restore feature.

                                  Randall Cotton
                                  Micro Resource Center Staff
                                  Computing Services Office
                                  University of Illinois Urbana/Champaign
                                  [e-mail] (128.174.73.105)
                                  (217)-244-6264

                                  this document last updated: July 6, 1989